Development and testing of an application program in environments such as Java™ often require constant switching between code writing and running. The re-starting of application e.g. for testing after making changes to the source code is often a quite time and resource consuming task.
The runtime environments, e.g. Java™, where the application code may be run, are often large and complex. Since the first release of Java™ language Java developers could not benefit from rapid development as Java Virtual Machine (JVM) did not support a way to reload classes after they have been loaded at least once by some class loader. Starting the environment and application program for testing may thus require a relatively long time, e.g. even several minutes, because classes of the needed runtime environment along with classes of the application need to be re-loaded even if only one of the application's classes was changed.
A standard JVM supports reloading class loaders (a standard, modifiable component of a Java environment) along with all their classes. However, in such a case all the current class instances were lost, unless explicitly preserved via e.g. serialization. This was used to support application redeployment, but could not be used for supporting any generic fine-grained reloading.
Another approach called HotSwap for reloading classes while debugging is known in the prior art. It only allows changing the method bodies, not allowing updates to method signatures, classes and fields. Because of its limitations, this approach does not satisfy most programmers and is rarely used.
A scientific publication by Mikhail Dmitriev (a dissertation submitted for the Degree of Doctor of Philosophy, Department of Computing Science, University of Glasgow, March 2001) with title “Safe Class and Data Evolution in Large and Long-Lived Java™ Applications” provides an overview about some prior art solutions for reloading classes. The publication discusses solutions for the following interrelated areas: consistent and scalable evolution of persistent data and code, optimal build management, and runtime changes to applications.
U.S. Patent application US20020087958 teaches a method and apparatus of transforming a class. The method involves creating modified class such that each access to class field is replaced by invocation of access function for fetching. In the disclosed method, the class is split and converted into a modified class and/or a helper class.
After the transformation, a safe class sharing among several processes is achieved whereby the startup times and the memory usage for the processes are reduced. The inter-process communication (IPC) becomes faster.
U.S. Patent application US20040168163 teaches a system and method for shortening class loading process in Java program. The method and system has a class loader performing linking and initialization processes to generate run time data which is stored in accessible state in memory.
U.S. Pat. No. 6,901,591 discloses frameworks for invoking methods in virtual machines. The disclosure provides an internal class representation data structure for use by virtual machine at runtime. The data structure comprises method and a reference cell corresponding to the method.
U.S. Pat. No. 6,092,079 discloses an apparatus and method for updating an object without affecting the unique identity of the object. In the disclosed method, a second object is created which is an instance of a first class. The data from the first object is copied into the second object. The method table pointer of the first object is then changed to the method table of the second class. The data section of the first object is then reallocated according to the data requirements of the second class. The data in the second object is then converted to data in the first object. The resultant first object has both methods and data updated to the second class without passivating the object.
U.S. Pat. No. 5,974,428 teaches a method and apparatus for class version naming and mapping. In an embodiment of the disclosed invention, a class versioning and mapping system allows a user to request a desired class without knowing which class version is the most recent or correct version for the desired class. The class versioning and mapping system uses a version mapping mechanism to cross reference the requested class, select the most recent or best version of the requested class, and then return an object to the user that belongs to the selected class.
The prior art fails to teach a method and arrangement that allows efficiently re-loading a changed class into a runtime environment without re-loading a number of other, unchanged classes at the same time. A solution for efficiently re-loading classes whose body, interface and/or attributes have changed, is therefore desired.
The object of the present invention is to provide a method and system for efficiently re-loading changed classes in a computer arrangement comprising a run-time environment such as Java™ Virtual Machine.
The invention discloses a method, arrangement and computer program to re-load a changed class in a run-time environment.
Class reloading method and arrangement of the present invention is based on a combined effect of a plurality of functional components. One such functional component comprises a method to split the original class into a state class that will hold the state (i.e. attributes and their values) and a behavior class that will hold static program code derived from the code of the original class. The split may be performed during runtime e.g. by generating the state and behavior classes from the original class and deploying at least one of the generated classes in the runtime environment.
A further possible component comprises functionality to simulate the signature of the original class in the state class by proxying every method call in the state class through a runtime environment to a method of the last version of the respective behavior class. “Proxying” in this context means e.g. generating a proxy method e.g. in the state class that forwards the method call to another class.
A yet further possible component comprises functionality to redirect method calls made from the versioned code class through runtime system using reflection to ensure that last version of a behavior class is called. By using reflection, the use of default virtual machine invocation logic may be avoided. Reflection is functionality provided e.g. by a Java runtime environment (JRE).
In the present invention, actual class reloading into the runtime environment may occur e.g. when the file containing the original class is updated and a new versioned behavior class is created (generated) on the basis of the modified original class. The runtime system of the present invention makes sure that all subsequent method calls will be redirected to the latest version of the behavior class.
An aspect of the invention is a computer executable method for deploying an input class during runtime in a computer readable memory. The method is characterized in that the method comprises steps of (a) creating on the basis of the input class a state class comprising at least one field and at least one proxy method and a behavior class version comprising at least one method and (b) redirecting at least one method call of the state class to the behavior class version.
The correct version of the behavior class may be determined e.g. by a redirecting service. The version of the behavior class, to which the method call should be redirected, may further be determined during runtime.
The creation of the state class and/or the behavior class may be performed during runtime.
The redirecting service may invoke at least one method using reflection.
The behavior class may comprise version information.
A method of said behavior class may comprise a call to a method of a class of the redirecting service.
The method of the state class may comprise a call to a method of a class of said redirecting service.
Creating a class in this context means e.g. generating the class and deploying it in the computer readable memory for use of e.g. a runtime environment, e.g. a Java™ runtime environment.
The computer readable memory may contain a runtime environment that may be an object oriented runtime environment, e.g. a Java™ runtime environment.
The class may be a class of any suitable object oriented development and/or runtime environment e.g. a Java™ class.
Another aspect of the invention is an arrangement for deploying an input class in a computer readable memory during runtime. The arrangement is characterized in that it comprises means for (i) creating (generating) from the input class a state class comprising at least one field and at least one proxy method and (ii) means for creating (generating) from the input class a behavior class version comprising at least one method and (iii) means for redirecting at least one state class method call to the behavior class version.
The correct version of the behavior class to be used may be determined e.g. by the redirecting means.
Yet another aspect of the invention is software for deploying an input class in a computer readable memory during runtime, said software comprising computer executable program code for (i) creating (generating) from the input class a state class comprising at least one field and at least one proxy method, (ii) creating from the input class a behavior class version comprising at least one method and (iii) redirecting at least one state class method call to the behavior class version.
The correct version of the behavior class to be used may be determined e.g. by the redirecting program code of the software.
Some embodiments of the invention are described herein, and further applications and adaptations of the invention will be apparent to those of ordinary skill in the art.